<html>
<title>ELF Header</title>
<h1>ELF Header</h1>
<p>
Some object file control structures can grow, because the ELF header
contains their actual sizes. If the object file format changes, a program
may encounter control structures that are larger or smaller than expected.
Programs might therefore ignore ``extra'' information. The treatment of
``missing'' information depends on context and will be specified when and
if extensions are defined. 
<hr>
<b>Figure 4-3: ELF Header</b>
<p>
<pre>
<code>#define EI_NIDENT 16

typedef struct {
        unsigned char   e_ident[EI_NIDENT];
        Elf32_Half      e_type;
        Elf32_Half      e_machine;
        Elf32_Word      e_version;
        Elf32_Addr      e_entry;
        Elf32_Off       e_phoff;
        Elf32_Off       e_shoff;
        Elf32_Word      e_flags;
        Elf32_Half      e_ehsize;
        Elf32_Half      e_phentsize;
        Elf32_Half      e_phnum;
        Elf32_Half      e_shentsize;
        Elf32_Half      e_shnum;
        Elf32_Half      e_shstrndx;
} Elf32_Ehdr;

typedef struct {
        unsigned char   e_ident[EI_NIDENT];
        Elf64_Half      e_type;
        Elf64_Half      e_machine;
        Elf64_Word      e_version;
        Elf64_Addr      e_entry;
        Elf64_Off       e_phoff;
        Elf64_Off       e_shoff;
        Elf64_Word      e_flags;
        Elf64_Half      e_ehsize;
        Elf64_Half      e_phentsize;
        Elf64_Half      e_phnum;
        Elf64_Half      e_shentsize;
        Elf64_Half      e_shnum;
        Elf64_Half      e_shstrndx;
} Elf64_Ehdr;</code>
</pre>
<hr>
<dl compact>
<dt><code>e_ident</code></dt>
<dd>The initial bytes mark the file as an object file and 
provide machine-independent
data with which to decode and interpret the file's contents. 
Complete descriptions
appear below in <a href="#elfid">``ELF Identification''</a>. </dd>
<dt><code>e_type</code></dt>
<dd>This member identifies the object file type. </dd>
<p>
<table border cellspacing=0>
<tr>
<th><b>Name</b></th>
<th><b>Value</b></th>
<th><b>Meaning</b></th>
</tr>
<tr>
<td><code>ET_NONE</code></td>
<td align=right><code>0</code></td>
<td>No file type</td>
</tr>
<tr>
<td><code>ET_REL</code></td>
<td align=right><code>1</code></td>
<td>Relocatable file</td>
</tr>
<tr>
<td><code>ET_EXEC</code></td>
<td align=right><code>2</code></td>
<td>Executable file</td>
</tr>
<tr>
<td><code>ET_DYN</code></td>
<td align=right><code>3</code></td>
<td>Shared object file</td>
</tr>
<tr>
<td><code>ET_CORE</code></td>
<td align=right><code>4</code></td>
<td>Core file</td>
</tr>
<tr>
<td><code>ET_LOOS</code></td>
<td align=right><code>0xfe00</code></td>
<td>Operating system-specific</td>
</tr>
<tr>
<td><code>ET_HIOS</code></td>
<td align=right><code>0xfeff</code></td>
<td>Operating system-specific</td>
</tr>
<tr>
<td><code>ET_LOPROC</code></td>
<td align=right><code>0xff00</code></td>
<td>Processor-specific</td>
</tr>
<tr>
<td><code>ET_HIPROC</code></td>
<td align=right><code>0xffff</code></td>
<td>Processor-specific</td>
</tr>
</table>
<p>
Although the core file contents are unspecified, 
type <code>ET_CORE</code>
is reserved to mark the file. 
Values from <code>ET_LOOS</code> 
through <code>ET_HIOS</code>
(inclusive) are reserved for operating system-specific semantics.
Values from <code>ET_LOPROC</code> 
through <code>ET_HIPROC</code>
(inclusive) are reserved for processor-specific semantics. If meanings
are specified, the processor supplement explains them. Other values are
reserved and will be assigned to new object file types as necessary.
<p><a name="e_machine"></a>
<dt><code>e_machine</code></dt>
<dd>This member's value specifies the required architecture for
an individual file. </dd>
<p>
<table border cellspacing=0>
<tr>
<th><b>Name</b></th>
<th><b>Value</b></th>
<th><b>Meaning</b></th>
</tr>
<tr>
<td><code>EM_NONE</code></td>
<td align=right><code>0</code></td>
<td>No machine</td>
</tr>
<!-- AT&T, before 1994 -->
<tr>
<td><code>EM_M32</code></td>
<td align=right><code>1</code></td>
<td>AT&amp;T WE 32100</td>
</tr>
<!-- Sun Microsystems, before 1994 -->
<tr>
<td><code>EM_SPARC</code></td>
<td align=right><code>2</code></td>
<td>SPARC</td>
</tr>
<!-- USL, before 1994 -->
<tr>
<td><code>EM_386</code></td>
<td align=right><code>3</code></td>
<td>Intel 80386</td>
</tr>
<!-- before 1994 -->
<tr>
<td><code>EM_68K</code></td>
<td align=right><code>4</code></td>
<td>Motorola 68000</td>
</tr>
<!-- before 1994 -->
<tr>
<td><code>EM_88K</code></td>
<td align=right><code>5</code></td>
<td>Motorola 88000</td>
</tr>
<!-- before 1994, was EM_486, Intel 80486 -->
<tr>
<td align=right>reserved</td>
<td align=right><code>6</code></td>
<td>Reserved for future use (was <code>EM_486</code>)</td>
</tr>
<!-- before 1994 -->
<tr>
<td><code>EM_860</code></td>
<td align=right><code>7</code></td>
<td>Intel 80860</td>
</tr>
<!-- before 1994 -->
<tr>
<td><code>EM_MIPS</code></td>
<td align=right><code>8</code></td>
<td>MIPS I Architecture</td>
</tr>
<!-- Amdahl? before 1994, then Hannaford Bros, 10/99 -->
<tr>
<td><code>EM_S370</code></td>
<td align=right><code>9</code></td>
<td>IBM System/370 Processor</td>
</tr>
<!-- before 1994 -->
<tr>
<td><code>EM_MIPS_RS3_LE</code></td>
<td align=right><code>10</code></td>
<td>MIPS RS3000 Little-endian</td>
</tr>
<!-- before 1994, 11 reserved for RS/6000 -->
<tr>
<td align=right>reserved</td>
<td align=right><code>11-14</code></td>
<td>Reserved for future use</td>
</tr>
<!-- Hewlett-Packard, before 1994 -->
<tr>
<td><code>EM_PARISC</code></td>
<td align=right><code>15</code></td>
<td>Hewlett-Packard PA-RISC</td>
</tr>
<!-- before 1994, reserved for nCUBE -->
<tr>
<td align=right>reserved</td>
<td align=right><code>16</code></td>
<td>Reserved for future use</td>
</tr>
<!-- Fujitsu, 4/94 -->
<tr>
<td><code>EM_VPP500</code></td>
<td align=right><code>17</code></td>
<td>Fujitsu VPP500</td>
</tr>
<!-- SunSoft, 7/94 -->
<tr>
<td><code>EM_SPARC32PLUS</code></td>
<td align=right><code>18</code></td>
<td>Enhanced instruction set SPARC</td>
</tr>
<!-- TIS, 10/94 -->
<tr>
<td><code>EM_960</code></td>
<td align=right><code>19</code></td>
<td>Intel 80960</td>
</tr>
<!-- TIS, 10/94 -->
<tr>
<td><code>EM_PPC</code></td>
<td align=right><code>20</code></td>
<td>PowerPC</td>
</tr>
<!-- TIS, 10/94, then IBM 10/99 -->
<tr>
<td><code>EM_PPC64</code></td>
<td align=right><code>21</code></td>
<td>64-bit PowerPC</td>
</tr>
<!-- IBM (Deutschland) by Martin Schwidefsky, 12/00 -->
<tr>
<td><code>EM_S390</code></td>
<td align=right><code>22</code></td>
<td>IBM System/390 Processor</td>
</tr>
<!-- TIS, 10/94, reserved for Power/PowerPC -->
<tr>
<td align=right>reserved</td>
<td align=right><code>23-35</code></td>
<td>Reserved for future use</td>
</tr>
<!-- Green Hills Software, 6/95 -->
<tr>
<td><code>EM_V800</code></td>
<td align=right><code>36</code></td>
<td>NEC V800</td>
</tr>
<!-- Green Hills Software, 7/95 -->
<tr>
<td><code>EM_FR20</code></td>
<td align=right><code>37</code></td>
<td>Fujitsu FR20</td>
</tr>
<!-- Green Hills Software, 9/95 -->
<tr> <td><code>EM_RH32</code></td>
<td align=right><code>38</code></td>
<td>TRW RH-32</td>
</tr>
<!-- Motorola, 12/95 -->
<tr>
<td><code>EM_RCE</code></td>
<td align=right><code>39</code></td>
<td>Motorola RCE</td>
</tr>
<!-- Green Hills Software, 3/96 -->
<tr>
<td><code>EM_ARM</code></td>
<td align=right><code>40</code></td>
<td>Advanced RISC Machines ARM</td>
</tr>
<!-- Digital, 5/96 -->
<tr>
<td><code>EM_ALPHA</code></td>
<td align=right><code>41</code></td>
<td>Digital Alpha</td>
</tr>
<!-- Green Hills Software, 5/96 -->
<tr>
<td><code>EM_SH</code></td>
<td align=right><code>42</code></td>
<td>Hitachi SH</td>
</tr>
<!-- Sun Microsystems, 6/96 -->
<tr>
<td><code>EM_SPARCV9</code></td>
<td align=right><code>43</code></td>
<td>SPARC Version 9</td>
</tr>
<!-- Green Hills Software, 9/96 -->
<tr>
<td><code>EM_TRICORE</code></td>
<td align=right><code>44</code></td>
<td>Siemens TriCore embedded processor</td>
</tr>
<!-- MetaWare, 12/96 -->
<tr>
<td><code>EM_ARC</code></td>
<td align=right><code>45</code></td>
<td>Argonaut RISC Core, Argonaut Technologies Inc.</td>
</tr>
<!-- Hitachi, 1/97 -->
<tr>
<td><code>EM_H8_300</code></td>
<td align=right><code>46</code></td>
<td>Hitachi H8/300</td>
</tr>
<!-- Hitachi, 1/97 -->
<tr>
<td><code>EM_H8_300H</code></td>
<td align=right><code>47</code></td>
<td>Hitachi H8/300H</td>
</tr>
<!-- Hitachi, 1/97 -->
<tr>
<td><code>EM_H8S</code></td>
<td align=right><code>48</code></td>
<td>Hitachi H8S</td>
</tr>
<!-- Hitachi, 1/97 -->
<tr>
<td><code>EM_H8_500</code></td>
<td align=right><code>49</code></td>
<td>Hitachi H8/500</td>
</tr>
<!-- Intel, 1/97 -->
<tr>
<td><code>EM_IA_64</code></td>
<td align=right><code>50</code></td>
<td>Intel IA-64 processor architecture</td>
</tr>
<!-- Green Hills Software, 2/97 -->
<tr>
<td><code>EM_MIPS_X</code></td>
<td align=right><code>51</code></td>
<td>Stanford MIPS-X</td>
</tr>
<!-- Green Hills Software, 5/97 -->
<tr>
<td><code>EM_COLDFIRE</code></td>
<td align=right><code>52</code></td>
<td>Motorola ColdFire</td>
</tr>
<!-- Motorola, 11/97 -->
<tr>
<td><code>EM_68HC12</code></td>
<td align=right><code>53</code></td>
<td>Motorola M68HC12</td>
</tr>
<!-- Green Hills Software, 5/98 -->
<tr>
<td><code>EM_MMA</code></td>
<td align=right><code>54</code></td>
<td>Fujitsu MMA Multimedia Accelerator</td>
</tr>
<!-- Green Hills Software, 5/98 -->
<tr>
<td><code>EM_PCP</code></td>
<td align=right><code>55</code></td>
<td>Siemens PCP</td>
</tr>
<!-- Green Hills Software, 5/98 -->
<tr>
<td><code>EM_NCPU</code></td>
<td align=right><code>56</code></td>
<td>Sony nCPU embedded RISC processor</td>
</tr>
<!-- Green Hills Software, 6/98 -->
<tr>
<td><code>EM_NDR1</code></td>
<td align=right><code>57</code></td>
<td>Denso NDR1 microprocessor</td>
</tr>
<!-- Green Hills Software, 10/98 -->
<tr>
<td><code>EM_STARCORE</code></td>
<td align=right><code>58</code></td>
<td>Motorola Star*Core processor</td>
</tr>
<!-- Green Hills Software, 10/98 -->
<tr>
<td><code>EM_ME16</code></td>
<td align=right><code>59</code></td>
<td>Toyota ME16 processor</td>
</tr>
<!-- Green Hills Software, 12/98 -->
<tr>
<td><code>EM_ST100</code></td>
<td align=right><code>60</code></td>
<td>STMicroelectronics ST100 processor</td>
</tr>
<!-- Advanced Logic Corp., 1/99 -->
<tr>
<td><code>EM_TINYJ</code></td>
<td align=right><code>61</code></td>
<td>Advanced Logic Corp. TinyJ embedded processor family</td>
</tr>
<!-- CodeSourcery, 2000 -->
<tr>
<td><code>EM_X86_64</code></td>
<td align=right><code>62</code></td>
<td>AMD x86-64 architecture</td>
</tr>
<!-- Green Hills, 2000 -->
<tr>
<td><code>EM_PDSP</code></td>
<td align=right><code>63</code></td>
<td>Sony DSP Processor</td>
</tr>
<!-- Lars Brinkoff, lars@nocrew.org, 30 May 2002 -->
<tr>
<td><code>EM_PDP10</code></td>
<td align=right><code>64</code></td>
<td>Digital Equipment Corp. PDP-10</td>
</tr>
<!-- Lars Brinkoff, lars@nocrew.org, 30 May 2002 -->
<tr>
<td><code>EM_PDP11</code></td>
<td align=right><code>65</code></td>
<td>Digital Equipment Corp. PDP-11</td>
</tr>
<!-- Siemens AG, 6/98 -->
<tr>
<td><code>EM_FX66</code></td>
<td align=right><code>66</code></td>
<td>Siemens FX66 microcontroller</td>
</tr>
<!-- STMicroelectronics, 6/99 -->
<tr>
<td><code>EM_ST9PLUS</code></td>
<td align=right><code>67</code></td>
<td>STMicroelectronics ST9+ 8/16 bit microcontroller</td>
</tr>
<!-- STMicroelectronics, 6/99 -->
<tr>
<td><code>EM_ST7</code></td>
<td align=right><code>68</code></td>
<td>STMicroelectronics ST7 8-bit microcontroller</td>
</tr>
<!-- Motorola, 6/99 -->
<tr>
<td><code>EM_68HC16</code></td>
<td align=right><code>69</code></td>
<td>Motorola MC68HC16 Microcontroller</td>
</tr>
<!-- Motorola, 6/99 -->
<tr>
<td><code>EM_68HC11</code></td>
<td align=right><code>70</code></td>
<td>Motorola MC68HC11 Microcontroller</td>
</tr>
<!-- Motorola, 6/99 -->
<tr>
<td><code>EM_68HC08</code></td>
<td align=right><code>71</code></td>
<td>Motorola MC68HC08 Microcontroller</td>
</tr>
<!-- Motorola, 6/99 -->
<tr>
<td><code>EM_68HC05</code></td>
<td align=right><code>72</code></td>
<td>Motorola MC68HC05 Microcontroller</td>
</tr>
<!-- Silicon Graphics, 6/99 -->
<tr>
<td><code>EM_SVX</code></td>
<td align=right><code>73</code></td>
<td>Silicon Graphics SVx</td>
</tr>
<!-- STMicroelectronics, 6/99 -->
<tr>
<td><code>EM_ST19</code></td>
<td align=right><code>74</code></td>
<td>STMicroelectronics ST19 8-bit microcontroller</td>
</tr>
<!-- 3am Software Foundry, 8/99 -->
<tr>
<td><code>EM_VAX</code></td>
<td align=right><code>75</code></td>
<td>Digital VAX</td>
<!-- Axis Communications AB, 10/99 -->
<tr>
<td><code>EM_CRIS</code></td>
<td align=right><code>76</code></td>
<td>Axis Communications 32-bit embedded processor</td>
</tr>
<!-- Infineon Technologies, 10/99 -->
<tr>
<td><code>EM_JAVELIN</code></td>
<td align=right><code>77</code></td>
<td>Infineon Technologies 32-bit embedded processor</td>
</tr>
<!-- Green Hills Software, 11/99 -->
<tr>
<td><code>EM_FIREPATH</code></td>
<td align=right><code>78</code></td>
<td>Element 14 64-bit DSP Processor</td>
</tr>
<!-- Green Hills Software, 11/99 -->
<tr>
<td><code>EM_ZSP</code></td>
<td align=right><code>79</code></td>
<td>LSI Logic 16-bit DSP Processor</td>
</tr>
<!-- MMIXmasters  volunteer organization, 2/00 -->
<tr>
<td><code>EM_MMIX</code></td>
<td align=right><code>80</code></td>
<td>Donald Knuth's educational 64-bit processor</td>
</tr>
<!-- Harvard University, Division of Engineering and Applied Sciences 3/00 -->
<tr>
<td><code>EM_HUANY</code></td>
<td align=right><code>81</code></td>
<td>Harvard University machine-independent object files</td>
</tr>
</tr>
<!-- Cygnus 4/00 -->
<tr>
<td><code>EM_PRISM</code></td>
<td align=right><code>82</code></td>
<td>SiTera Prism</td>
</tr>
<!-- RedHat, 11/2000 -->
<tr>
<td><code>EM_AVR</code></td>
<td align=right><code>83</code></td>
<td>Atmel AVR 8-bit microcontroller</td>
</tr>
<tr>
<td><code>EM_FR30</code></td>
<td align=right><code>84</code></td>
<td>Fujitsu FR30</td>
</tr>
<tr>
<td><code>EM_D10V</code></td>
<td align=right><code>85</code></td>
<td>Mitsubishi D10V</td>
</tr>
<tr>
<td><code>EM_D30V</code></td>
<td align=right><code>86</code></td>
<td>Mitsubishi D30V</td>
</tr>
<tr>
<td><code>EM_V850</code></td>
<td align=right><code>87</code></td>
<td>NEC v850</td>
</tr>
<tr>
<td><code>EM_M32R</code></td>
<td align=right><code>88</code></td>
<td>Mitsubishi M32R</td>
</tr>
<tr>
<td><code>EM_MN10300</code></td>
<td align=right><code>89</code></td>
<td>Matsushita MN10300</td>
</tr>
<tr>
<td><code>EM_MN10200</code></td>
<td align=right><code>90</code></td>
<td>Matsushita MN10200</td>
</tr>
<tr>
<td><code>EM_PJ</code></td>
<td align=right><code>91</code></td>
<td>picoJava</td>
</tr>
<tr>
<td><code>EM_OPENRISC</code></td>
<td align=right><code>92</code></td>
<td>OpenRISC 32-bit embedded processor</td>
</tr>
<!-- MetaWare, 3 May 2001 -->
<tr>
<td><code>EM_ARC_A5</code></td>
<td align=right><code>93</code></td>
<td>ARC Cores Tangent-A5</td>
</tr>
<!-- Tensilica, Inc. 16 May 2001 -->
<!-- Bob Wilson and David Heine (bwilson@ and dlheine@tensilica.com) -->
<tr>
<td><code>EM_XTENSA</code></td>
<td align=right><code>94</code></td>
<td>Tensilica Xtensa Architecture</td>
</tr>
<!-- 5 Jul 2001 for Dom Cobley (dom.cobley@camcon.co.uk) -->
<tr>
<td><code>EM_VIDEOCORE</code></td>
<td align=right><code>95</code></td>
<td>Alphamosaic VideoCore processor</td>
</tr>
<!-- 19 Jul 2001 for Harshad R. Joglekar (harshad.joglekar@wipro.com) -->
<tr>
<td><code>EM_TMM_GPP</code></td>
<td align=right><code>96</code></td>
<td>Thompson Multimedia General Purpose Processor</td>
</tr>
<!-- 29 Oct 2001 for Simon Burge (simonb@wasabisystems.com) NetBSD -->
<tr>
<td><code>EM_NS32K</code></td>
<td align=right><code>97</code></td>
<td>National Semiconductor 32000 series</td>
</tr>
<!-- 7 Jun 2002 for Alan Lehotsky (apl@alum.mit.edu) -->
<tr>
<td><code>EM_TPC</code></td>
<td align=right><code>98</code></td>
<td>Tenor Network TPC processor</td>
</tr>
<!-- 7 Jun 2002 for Alan Lehotsky (apl@alum.mit.edu) -->
<tr>
<td><code>EM_SNP1K</code></td>
<td align=right><code>99</code></td>
<td>Trebia SNP 1000 processor</td>
</tr>
<!-- 10 Jun 2002 for Christian Bertin (Christian Bertin@st.com) -->
<tr>
<td><code>EM_ST200</code></td>
<td align=right><code>100</code></td>
<td>STMicroelectronics (www.st.com) ST200 microcontroller</td>
</tr>
</table>
<p>
Other values are reserved and will be assigned to new machines 
as necessary.
Processor-specific ELF names use the machine name to distinguish them.
For example, the flags mentioned below use the 
prefix <code>EF_</code>;
a flag named <code>WIDGET</code> for the <code>EM_XYZ</code>
machine would be called <code>EF_XYZ_WIDGET</code>.
<dt><code>e_version</code></dt>
<dd>This member identifies the object file version. </dd>
<p>
<table border cellspacing=0>
<tr>
<th><b>Name</b></th>
<th><b>Value</b></th>
<th><b>Meaning</b></th>
</tr>
<tr>
<td><code>EV_NONE</code></td>
<td align=right><code>0</code></td>
<td>Invalid version</td>
</tr>
<tr>
<td><code>EV_CURRENT</code></td>
<td align=right><code>1</code></td>
<td>Current version</td>
</tr>
</table>
<p>
The value <code>1</code> signifies the original file format; 
extensions will create new versions with higher numbers. 
Although the value of <code>EV_CURRENT</code>
is shown as <code>1</code> in the previous table, it will 
change as necessary to reflect the current version number.
<dt><code>e_entry</code></dt>
<dd>This member gives the virtual address to which the 
system first transfers
control, thus starting the process. If the file has no associated entry
point, this member holds zero. </dd>
<dt><code>e_phoff</code></dt>
<dd>This member holds the program header table's file offset in bytes.
If the file has no program header table, this member holds zero. </dd>
<dt><code>e_shoff</code></dt>
<dd>This member holds the section header table's file offset in bytes.
If the file has no section header table, this member holds zero. </dd>
<dt><code>e_flags</code></dt>
<dd>This member holds processor-specific flags associated with the file.
Flag names take the form 
<code>EF_</code><i>machine</i><b>_</b><i>flag</i>.  </dd>
<dt><code>e_ehsize</code></dt>
<dd>This member holds the ELF header's size in bytes. </dd>
<dt><code>e_phentsize</code></dt>
<dd>This member holds the size in bytes of one entry in the file's program
header table; all entries are the same size. </dd>
<dt><code>e_phnum</code></dt>
<dd>This member holds the number of entries in the program header table.
Thus the product of 
<code>e_phentsize</code> and <code>e_phnum</code> gives the
table's size in bytes. 
If a file has no program header table, <code>e_phnum</code>
holds the value zero. </dd>
<dt><code>e_shentsize</code></dt>
<dd>This member holds a section header's size in bytes. A section header
is one entry in the section header table; all entries are the same size.
</dd>
<dt><code>e_shnum</code></dt>
<a name=many_sections></a>
<dd>This member holds the number of entries in the section header table.
Thus the product of <code>e_shentsize</code> and 
<code>e_shnum</code> gives the
section header table's size in bytes. 
If a file has no section header table,
<code>e_shnum</code> holds the value zero.
<p>
If the number of sections is greater than or equal to
<code>SHN_LORESERVE</code> (<code>0xff00</code>), this member
has the value zero and the actual number of section header table
entries is contained in the <code>sh_size</code> field of
the section header at index <code>0</code>.
(Otherwise, the <code>sh_size</code> member of the initial entry 
contains <code>0</code>.)
</dd>
<dt><code>e_shstrndx</code></dt>
<dd>This member holds the section header table index of the 
entry associated with the section name string table. 
If the file has no section name string
table, this member holds the value <code>SHN_UNDEF</code>. 
See <a href="ch4.sheader.html">``Sections''</a>
and <a href="ch4.strtab.html">``String Table''</a> below 
for more information.
<p>
If the section name string table section index is greater than or equal to
<code>SHN_LORESERVE</code> (<code>0xff00</code>), this member
has the value <code>SHN_XINDEX</code> (<code>0xffff</code>) and the
actual index of the section name string table section
is contained in the <code>sh_link</code> field of
the section header at index <code>0</code>.
(Otherwise, the <code>sh_link</code> member of the initial entry 
contains <code>0</code>.)
</dd>
</dl>
<p><a name="elfid"></a>
<h2>ELF Identification</h2>
<p>
As mentioned above, ELF provides an object file framework to support
multiple processors, multiple data encodings, and multiple 
classes of machines.  To support this object file family, 
the initial bytes of the file specify
how to interpret the file, independent of the processor on 
which the inquiry is made and independent of the file's 
remaining contents.
<p>
The initial bytes of an ELF header (and an object file) correspond to
the <code>e_ident</code> member.
<hr>
<b>Figure 4-4: </b><code>e_ident[]</code> <b>Identification Indexes</b>
<p>
<table border cellspacing=0>
<tr>
<th><b>Name</b></th>
<th><b>Value</b></th>
<th><b>Purpose</b></th>
</tr>
<tr>
<td><code>EI_MAG0</code></td>
<td align=right><code>0</code></td>
<td>File identification</td>
</tr>
<tr>
<td><code>EI_MAG1</code></td>
<td align=right><code>1</code></td>
<td>File identification</td>
</tr>
<tr>
<td><code>EI_MAG2</code></td>
<td align=right><code>2</code></td>
<td>File identification</td>
</tr>
<tr>
<td><code>EI_MAG3</code></td>
<td align=right><code>3</code></td>
<td>File identification</td>
</tr>
<tr>
<td><code>EI_CLASS</code></td>
<td align=right><code>4</code></td>
<td>File class</td>
</tr>
<tr>
<td><code>EI_DATA</code></td>
<td align=right><code>5</code></td>
<td>Data encoding</td>
</tr>
<tr>
<td><code>EI_VERSION</code></td>
<td align=right><code>6</code></td>
<td>File version</td>
</tr>
<tr>
<td><code>EI_OSABI</code></td>
<td align=right><code>7</code></td>
<td>Operating system/ABI identification</td>
</tr>
<tr>
<td><code>EI_ABIVERSION</code></td>
<td align=right><code>8</code></td>
<td>ABI version</td>
</tr>
<tr>
<td><code>EI_PAD</code></td>
<td align=right><code>9</code></td>
<td>Start of padding bytes</td>
</tr>
<tr>
<td><code>EI_NIDENT</code></td>
<td align=right><code>16</code></td>
<td>Size of <code>e_ident[]</code></td>
</tr>
</table>
<hr>
<p>
These indexes access bytes that hold the following values.
<dl compact>
<dt><code>EI_MAG0</code>&nbsp;to&nbsp;<code>EI_MAG3</code></dt>
<dd>A file's first 4 bytes hold a ``magic number,'' identifying the file
as an ELF object file. </dd>
<p>
<table border cellspacing=0>
<tr>
<th><b>Name</b></th>
<th><b>Value</b></th>
<th><b>Position</b></th>
</tr>
<tr>
<td><code>ELFMAG0</code></td>
<td align=right><code>0x7f</code></td>
<td><code>e_ident[EI_MAG0]</code></td>
</tr>
<tr>
<td><code>ELFMAG1</code></td>
<td align=right><code>'E'</code></td>
<td><code>e_ident[EI_MAG1]</code></td>
</tr>
<tr>
<td><code>ELFMAG2</code></td>
<td align=right><code>'L'</code></td>
<td><code>e_ident[EI_MAG2]</code></td>
</tr>
<tr>
<td><code>ELFMAG3</code></td>
<td align=right><code>'F'</code></td>
<td><code>e_ident[EI_MAG3]</code></td>
</tr>
</table>
<p>
<dt><code>EI_CLASS</code></dt>
<dd>The next byte, <code>e_ident[EI_CLASS]</code>, identifies the 
file's class, or capacity. </dd>
<p>
<table border cellspacing=0>
<tr>
<th><b>Name</b></th>
<th><b>Value</b></th>
<th><b>Meaning</b></th>
</tr>
<tr>
<td><code>ELFCLASSNONE</code></td>
<td align=right><code>0</code></td>
<td>Invalid class</td>
</tr>
<tr>
<td><code>ELFCLASS32</code></td>
<td align=right><code>1</code></td>
<td>32-bit objects</td>
</tr>
<tr>
<td><code>ELFCLASS64</code></td>
<td align=right><code>2</code></td>
<td>64-bit objects</td>
</tr>
</table>
<p>
The file format is designed to be portable among machines of various
sizes, without imposing the sizes of the largest machine on the 
smallest.  The class of the file defines the basic types 
used by the data structures
of the object file container itself. The data contained in object file
sections may follow a different programming model. If so, the processor
supplement describes the model used.
<p>
Class <code>ELFCLASS32</code> supports machines with 
32-bit architectures. It
uses the basic types defined in the table 
labeled ``32-Bit Data Types.''
<p>
Class <code>ELFCLASS64</code> supports machines with 64-bit 
architectures.  It uses the basic types defined in the table 
labeled ``64-Bit Data Types.''
<p>
Other classes will be defined as necessary, with different basic types
and sizes for object file data.
<dt><code>EI_DATA</code></dt>
<dd>Byte <code>e_ident[EI_DATA]</code> specifies the
encoding of both the data structures used by object file container
and data contained in object file sections.
The following encodings are currently defined.
</dd>
<p>
<table border cellspacing=0>
<tr>
<th><b>Name</b></th>
<th><b>Value</b></th>
<th><b>Meaning</b></th>
</tr>
<tr>
<td><code>ELFDATANONE</code></td>
<td align=right><code>0</code></td>
<td>Invalid data encoding</td>
</tr>
<tr>
<td><code>ELFDATA2LSB</code></td>
<td align=right><code>1</code></td>
<td>See below</td>
</tr>
<tr>
<td><code>ELFDATA2MSB</code></td>
<td align=right><code>2</code></td>
<td>See below</td>
</tr>
</table>
<p>
Other values are reserved and will be assigned to new 
encodings as necessary.
<p>
<hr><img src="warning.gif" alt="NOTE:"> 
Primarily for the convenience of code that looks at the ELF
file at runtime, the ELF data structures are intended to have the
same byte order as that of the running program.
<hr>
<dt><code>EI_VERSION</code></dt>
<dd>Byte <code>e_ident[EI_VERSION]</code> specifies the 
ELF header version
number. Currently, this value must be <code>EV_CURRENT</code>, 
as explained above for <code>e_version</code>. </dd>
<p><a name="osabi"></a>
<dt><code>EI_OSABI</code></dt>
<dd>Byte <code>e_ident[EI_OSABI]</code> identifies the
OS- or ABI-specific ELF extensions used by this file.
Some fields in other ELF structures have flags and values
that have operating system and/or ABI specific meanings;
the interpretation of those fields is determined by the value of this byte.
If the object file does not use any extensions,
it is recommended that this byte be set to <code>0</code>.
If the value for this byte is <code>64</code> through <code>255</code>,
its meaning depends on the value of the <code>e_machine</code> header member.
The ABI processor supplement for an architecture
can define its own associated set of values for this byte in this range.
If the processor supplement does not specify a set of values,
one of the following values shall be used,
where <code>0</code> can also be taken to mean <i>unspecified</i>.
<p>
<a name=generic_osabi_values></a>
<table border cellspacing=0>
<tr>
<th><b>Name</b></th>
<th><b>Value</b></th>
<th><b>Meaning</b></th>
</tr>
<tr>
<td><code>ELFOSABI_NONE</code></td>
<td align=right><code>0</code></td>
<td>No extensions or unspecified</td>
</tr>
<tr>
<td><code>ELFOSABI_HPUX</code></td>
<td align=right><code>1</code></td>
<td>Hewlett-Packard HP-UX</td>
</tr>
<tr>
<td><code>ELFOSABI_NETBSD</code></td>
<td align=right><code>2</code></td>
<td>NetBSD</td>
</tr>
<tr>
<td><code>ELFOSABI_LINUX</code></td>
<td align=right><code>3</code></td>
<td>Linux</td>
</tr>
<!-- 4 reserved for IA32 GNU Mach/Hurd -->
<!-- 5 reserved for 86Open common IA32 ABI -->
<tr>
<td><code>ELFOSABI_SOLARIS</code></td>
<td align=right><code>6</code></td>
<td>Sun Solaris</td>
</tr>
<tr>
<td><code>ELFOSABI_AIX</code></td>
<td align=right><code>7</code></td>
<td>AIX</td>
</tr>
<tr>
<td><code>ELFOSABI_IRIX</code></td>
<td align=right><code>8</code></td>
<td>IRIX</td>
</tr>
<tr>
<td><code>ELFOSABI_FREEBSD</code></td>
<td align=right><code>9</code></td>
<td>FreeBSD</td>
</tr>
<tr>
<td><code>ELFOSABI_TRU64</code></td>
<td align=right><code>10</code></td>
<td>Compaq TRU64 UNIX</td>
</tr>
<tr>
<td><code>ELFOSABI_MODESTO</code></td>
<td align=right><code>11</code></td>
<td>Novell Modesto</td>
</tr>
<tr>
<td><code>ELFOSABI_OPENBSD</code></td>
<td align=right><code>12</code></td>
<td>Open BSD</td>
</tr>
<!-- For Ron Brender (Ron.Brender@hp.com) 7 Jun 2002 -->
<tr>
<td><code>ELFOSABI_OPENVMS</code></td>
<td align=right><code>13</code></td>
<td>Open VMS</td>
</tr>
<!-- For Cary Coutant (cary@cup.hp.com) 7 Jun 2002 -->
<tr>
<td><code>ELFOSABI_NSK</code></td>
<td align=right><code>14</code></td>
<td>Hewlett-Packard Non-Stop Kernel</td>
</tr>
<tr>
<td>&nbsp;</td>
<td align=right><code>64-255</code></td>
<td>Architecture-specific value range</td>
</tr>
</table>
</dd>
<p><a name="abiversion"></a>
<dt><code>EI_ABIVERSION</code></dt>
<dd>Byte <code>e_ident[EI_ABIVERSION]</code> identifies the 
version of the ABI to which the object is targeted.
This field is used to distinguish among incompatible versions
of an ABI.  The interpretation of this version number
is dependent on the ABI identified by the <code>EI_OSABI</code>
field.  If no values are specified for the <code>EI_OSABI</code>
field by the processor supplement or no version values are
specified for the ABI determined by a particular value of the
<code>EI_OSABI</code> byte, the value <code>0</code> shall
be used for the <code>EI_ABIVERSION</code> byte; it
indicates <i>unspecified</i>.</dd>
<p>
<dt><code>EI_PAD</code></dt>
<dd>This value marks the beginning of the unused bytes in 
<code>e_ident</code>.  These bytes are reserved and set to zero; 
programs that read object files
should ignore them. The value of <code>EI_PAD</code> will 
change in the future if currently unused bytes are given 
meanings. </dd>
</dl>
<p>
A file's data encoding specifies how to interpret the basic objects
in a file. Class <code>ELFCLASS32</code> files use objects 
that occupy 1, 2, and 4 bytes. Class <code>ELFCLASS64</code> files
use objects that occupy 1, 2, 4, and 8 bytes. Under the defined
encodings, objects are represented as shown below.
<p>
Encoding <code>ELFDATA2LSB</code> specifies 2's complement values,
with the least significant byte occupying the lowest address. 
<hr>
<b>Figure 4-5: Data Encoding</b> <code>ELFDATA2LSB</code>, byte address zero on the left 
<p>
<table border=1 cellspacing=0 cellpadding=0 >
<tr>
<td align=center valign=center width="48" height="24">01</td>
</tr>
<caption align=bottom>0x01</caption>
</table>
<p>
<table border=1 cellspacing=0 cellpadding=0 >
<tr>
<td align=center valign=center width="48" height="24">02</td>
<td align=center valign=center width="48" height="24">01</td>
</tr>
<caption align=bottom>0x0102</caption>
</table>
<p>
<table border=1 cellspacing=0 cellpadding=0 >
<tr>
<td align=center valign=center width="48" height="24">04</td>
<td align=center valign=center width="48" height="24">03</td>
<td align=center valign=center width="48" height="24">02</td>
<td align=center valign=center width="48" height="24">01</td>
</tr>
<caption align=bottom>0x01020304</caption>
</table>
<p>
<table border=1 cellspacing=0 cellpadding=0 >
<tr>
<td align=center Valign=center width="48" height="24">08</td>
<td align=center Valign=center width="48" height="24">07</td>
<td align=center Valign=center width="48" height="24">06</td>
<td align=center Valign=center width="48" height="24">05</td>
<td align=center Valign=center width="48" height="24">04</td>
<td align=center Valign=center width="48" height="24">03</td>
<td align=center Valign=center width="48" height="24">02</td>
<td align=center Valign=center width="48" height="24">01</td>
</tr>
<caption align=bottom>0x0102030405060708</caption>
</table>
<hr>
<p>
Encoding <code>ELFDATA2MSB</code> specifies 2's complement values,
with the most significant byte occupying the lowest address. 
<hr>
<b>Figure 4-6: Data Encoding</b> <code>ELFDATA2MSB</code>, byte address zero on the left 
<p>
<table border=1 cellspacing=0 cellpadding=0 >
<tr>
<td align=center Valign=center width="48" height="24">01</td>
</tr>
<caption align=bottom>0x01</caption>
</table>
<p>
<table border=1 cellspacing=0 cellpadding=0 >
<tr>
<td align=center Valign=center width="48" height="24">01</td>
<td align=center Valign=center width="48" height="24">02</td>
</tr>
<caption align=bottom>0x0102</caption>
</table>
<p>
<table border=1 cellspacing=0 cellpadding=0 >
<tr>
<td align=center Valign=center width="48" height="24">01</td>
<td align=center Valign=center width="48" height="24">02</td>
<td align=center Valign=center width="48" height="24">03</td>
<td align=center Valign=center width="48" height="24">04</td>
</tr>
<caption align=bottom>0x01020304</caption>
</table>
<p>
<table border=1 cellspacing=0 cellpadding=0 >
<tr>
<td align=center Valign=center width="48" height="24">01</td>
<td align=center Valign=center width="48" height="24">02</td>
<td align=center Valign=center width="48" height="24">03</td>
<td align=center Valign=center width="48" height="24">04</td>
<td align=center Valign=center width="48" height="24">05</td>
<td align=center Valign=center width="48" height="24">06</td>
<td align=center Valign=center width="48" height="24">07</td>
<td align=center Valign=center width="48" height="24">08</td>
</tr>
<caption align=bottom>0x0102030405060708</caption>
</table>
<hr>
<p>
<a name="machine"></a></p>
<h2>Machine Information (Processor-Specific)</h2>
<p>
<hr><img src="warning.gif" alt="NOTE:"> 
This section requires processor-specific information.
The ABI supplement for the desired processor describes the details. 
<hr>
<a href="ch4.intro.html"><img src="previous.gif" alt="Previous"></a>
<a href="contents.html"><img src="contents.gif" alt="Contents"></a>
<a href="ch4.sheader.html"><img src="next.gif" alt="Next"></a>
<hr>
<i>
<small>
&#169; 1997, 1998, 1999, 2000, 2001 The Santa Cruz Operation, Inc.  All rights reserved.
&#169; 2002 Caldera International.  All rights reserved.
</small>
</i>
</html>
